[Amazon FSx for NetApp ONTAP] ボリュームを別SVMにリホストしてみた

[Amazon FSx for NetApp ONTAP] ボリュームを別SVMにリホストしてみた

リホストをするときは注意事項をよく確認してリホスト前後の設定を照らし合わせよう
Clock Icon2022.12.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

別のSVMにボリュームを移動させたいな

こんにちは、のんピ(@non____97)です。

皆さんは「Amazon FSx for NetApp ONTAP(以降FSx for ONTAP)のボリュームを別のSVMにリホストしたいな」と思ったことはありますか? 私はあります。

同じFSx for ONTAPファイルシステムに本番用SVMと検証用SVMがあり、検証用SVMで加工したデータをボリュームごと本番用SVMに持っていきたいみたいなこともあると思います。

NetApp公式ドキュメントを眺めているとボリュームを別SVMにリホストする機能がONTAPにあることが分かりました。

一般的にデータの移行であればSnapMirrorやDataSyncを使うと思いますが、設定するのが少し手間です。一方リホストであればボリュームごと移行することができるので、リホスト元のSVMからボリュームがなくなっても良いのであれば選択肢になるのかなと思います。

試してみたので紹介します。

いきなりまとめ

  • リホスト時にはボリュームへのアクセスを停止する必要がある
    • リホスト前にSVMからアンマウントする必要がある
  • リホストを行うとエクスポートポリシーやスナップショットポリシーなど一部設定が失われる
    • リホスト後に再設定してあげる必要がある

注意事項の確認

リホストにはいくつか注意事項があります。

注意事項はSMB、NFS、iSCSIとボリュームにアクセスするプロトコルによって異なります。

  • 共通
    • ボリュームはオンラインである必要がある
    • ボリュームの移動や LUN の移動など、ボリューム管理操作を実行してはならない
    • リホストするボリュームへのデータアクセスを停止する必要がある
  • SMBとNFS
    • リホストするボリュームのデータアクセスをサポートするようにターゲット SVM の ns-switch とネームサービスを設定する必要がある
    • ボリュームのユーザ ID とグループ ID をターゲット SVM で使用可能であるか、またはホストするボリュームを変更する必要がある
    • ローカルユーザとローカルグループが設定されていて、それらのユーザまたはグループに対して権限が設定されたボリューム上にファイルとディレクトリがある場合、それらの権限は無効になる
  • SMB
    • ソース SVM とデスティネーション SVM の Active Directory ドメインと DNS ドメインが同じであることが必要
    • ソース SVM とデスティネーション SVM の Active Directory ドメインが異なる場合は、ボリューム上のオブジェクトへのアクセスが失われる可能性がある
    • ソース SVM にローカルユーザとローカルグループが含まれている場合、ファイルとディレクトリに対して設定された権限( ACL )はボリュームのリホスト処理後に無効になる。監査 ACL ( SACL )についても同様
  • iSCSI
    • ボリュームまたは LUN にアクティブな I/O がないこと
    • デスティネーション SVM に同じ名前でイニシエータが異なる igroup がないことを確認しておく必要がある
    • igroup の名前が同じ場合は、どちらか(ソースまたはデスティネーション)の SVM で igroup の名前を変更する必要がある
    • force-unmap-luns オプションを有効にしておく必要がある

リホスト時に引き継がれない情報は以下の通りです。

  • 共通
    • ウィルス対策ポリシー
    • ボリューム効率化ポリシー
    • Quality of Service (QoS)ポリシー
    • スナップショットポリシー
    • ns-switch とネームサービスの設定のエクスポートポリシーとルール
    • ユーザ ID とグループ ID
  • SMBとNFS
    • ボリュームと qtree のエクスポートポリシー

参考 :

ボリュームへのアクセスを停止する必要がある & 設定が一部引き継がれないというのがポイントですね。リホストは基本的にワークロードが稼働していないメンテナンス期間に実施する方が良さそうです。

検証環境

検証環境は以下記事のものを流用します。

SVMはSVM1SVM2の2つを用意しました。こちらのSVM間でボリュームをリホスト(再割り当て)します。

$ aws fsx describe-storage-virtual-machines 
{
    "StorageVirtualMachines": [
        {
            "ActiveDirectoryConfiguration": {
                "NetBiosName": "SVM1",
                "SelfManagedActiveDirectoryConfiguration": {
                    "DomainName": "CORP.NON-97.NET",
                    "OrganizationalUnitDistinguishedName": "OU=FSxForONTAP,DC=corp,DC=non-97,DC=net",
                    "UserName": "FSxServiceAccount",
                    "DnsIps": [
                        "10.0.1.10"
                    ]
                }
            },
            "CreationTime": "2022-12-17T02:35:55.509000+00:00",
            "Endpoints": {
                "Iscsi": {
                    "DNSName": "iscsi.svm-0b0149bf226af89a4.fs-01f8ffb4adbf236d1.fsx.us-east-1.amazonaws.com",
                    "IpAddresses": [
                        "10.0.1.100",
                        "10.0.1.69"
                    ]
                },
                "Management": {
                    "DNSName": "svm-0b0149bf226af89a4.fs-01f8ffb4adbf236d1.fsx.us-east-1.amazonaws.com",
                    "IpAddresses": [
                        "10.0.1.119"
                    ]
                },
                "Nfs": {
                    "DNSName": "svm-0b0149bf226af89a4.fs-01f8ffb4adbf236d1.fsx.us-east-1.amazonaws.com",
                    "IpAddresses": [
                        "10.0.1.119"
                    ]
                },
                "Smb": {
                    "DNSName": "SVM1.CORP.NON-97.NET",
                    "IpAddresses": [
                        "10.0.1.119"
                    ]
                }
            },
            "FileSystemId": "fs-01f8ffb4adbf236d1",
            "Lifecycle": "CREATED",
            "Name": "SVM1",
            "ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:storage-virtual-machine/fs-01f8ffb4adbf236d1/svm-0b0149bf226af89a4",
            "StorageVirtualMachineId": "svm-0b0149bf226af89a4",
            "UUID": "90ccba40-7db3-11ed-a26f-3df7250d3ffe"
        },
        {
            "CreationTime": "2022-12-17T06:45:09.462000+00:00",
            "Endpoints": {
                "Iscsi": {
                    "DNSName": "iscsi.svm-0b0c9e66d39afdc54.fs-01f8ffb4adbf236d1.fsx.us-east-1.amazonaws.com",
                    "IpAddresses": [
                        "10.0.1.125",
                        "10.0.1.101"
                    ]
                },
                "Management": {
                    "DNSName": "svm-0b0c9e66d39afdc54.fs-01f8ffb4adbf236d1.fsx.us-east-1.amazonaws.com",
                    "IpAddresses": [
                        "10.0.1.104"
                    ]
                },
                "Nfs": {
                    "DNSName": "svm-0b0c9e66d39afdc54.fs-01f8ffb4adbf236d1.fsx.us-east-1.amazonaws.com",
                    "IpAddresses": [
                        "10.0.1.104"
                    ]
                }
            },
            "FileSystemId": "fs-01f8ffb4adbf236d1",
            "Lifecycle": "CREATED",
            "Name": "SVM2",
            "ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:storage-virtual-machine/fs-01f8ffb4adbf236d1/svm-0b0c9e66d39afdc54",
            "StorageVirtualMachineId": "svm-0b0c9e66d39afdc54",
            "UUID": "5c6616e0-7dd6-11ed-a26f-3df7250d3ffe"
        }
    ]
}

ボリュームのリホスト

早速ボリュームのリストアをします。vol1というSVM1上のボリュームをSVM2にリホストします。ボリュームのリホストはvolume rehostで行います。

# ボリュームの確認
::> volume show -fields junction-path
vserver volume    junction-path
------- --------- -------------
SVM1    SVM1_root /
SVM1    vol1      /vol1
SVM2    SVM2_root /
3 entries were displayed.

# vol1 を SVM1 から SVM2 にリホスト
::> volume rehost -vserver SVM1 -volume vol1 -destination-vserver SVM2

Warning: Rehosting a volume from one Vserver to another Vserver does not change the security information about that
         volume.
         If the security domains of the Vservers are not identical, unwanted access might be permitted, and desired access
         might be denied. An attempt to rehost a volume will disassociate the volume from all volume policies and policy
         rules. The volume must be reconfigured after a successful or unsuccessful rehost operation.
Do you want to continue? {y|n}: y
[Job 42] Job is queued: Volume rehost operation on volume "vol1" on Vserver "SVM1" to destination Vserver "SVM2" by administrator "fsxadmin".

Error: command failed: [Job 42] Job failed:
       Volume rehost precheck failed for reasons:

       Cannot rehost volume "vol1" on Vserver "SVM1" because the volume is part of a junction path. Use the "volume show
       -vserver SVM1 -volume vol1 -fields junction-path" command to view a volume's junction path. Use the "volume
       unmount" command to remove the junction path.

SVMのジャンクションパスにマウントされているためエラーとなりました。自動でアンマウントまでしてくれると思ったのですが、そこまではしてくれないようです。

ボリュームをSVM1からアンマウントして再チャレンジします。

# ボリュームのアンマウント
::> volume unmount -vserver SVM1 -volume vol1

# ボリュームがアンマウントされたことを確認
::> volume show -fields junction-path
vserver volume    junction-path
------- --------- -------------
SVM1    SVM1_root /
SVM1    vol1      -
SVM2    SVM2_root /
3 entries were displayed.

# vol1 を SVM1 から SVM2 にリホスト
::> volume rehost -vserver SVM1 -volume vol1 -destination-vserver SVM2

Warning: Rehosting a volume from one Vserver to another Vserver does not change the security information about that
         volume.
         If the security domains of the Vservers are not identical, unwanted access might be permitted, and desired access
         might be denied. An attempt to rehost a volume will disassociate the volume from all volume policies and policy
         rules. The volume must be reconfigured after a successful or unsuccessful rehost operation.
Do you want to continue? {y|n}: y
[Job 44] Job is queued: Volume rehost operation on volume "vol1" on Vserver "SVM1" to destination Vserver "SVM2" by adminis[Job 44] Job succeeded: Successful                                                                                         

Info: volume is rehosted on the target Vserver.
Set the desired volume configuration - such as the export policy and QoS policy - on the target Vserver.

# リホストされたことを確認
::> volume show -fields junction-path
vserver volume    junction-path
------- --------- -------------
SVM1    SVM1_root /
SVM2    SVM2_root /
SVM2    vol1      -
3 entries were displayed.

# vol1 を SVM2 の /vol1 にマウント
::> volume mount -vserver SVM2 -volume vol1 -junction-path /vol1

# vol1 を SVM2 の /vol1 にマウントされたことを確認
::> volume show -fields junction-path
vserver volume    junction-path
------- --------- -------------
SVM1    SVM1_root /
SVM2    SVM2_root /
SVM2    vol1      /vol1
3 entries were displayed.

# リホストしたボリュームのエクスポートポリシー、スナップショットポリシーの確認
::> volume show -vserver SVM2 -volume vol1 -fields policy, snapshot-policy
vserver volume policy  snapshot-policy
------- ------ ------- ---------------
SVM2    vol1   default default

アンマウントされた状態だとvol1SVM1上のボリュームをSVM2にリホストすることができました。

NFSクライアントからアクセスしてみます。

# ボリュームがマウントされていることを確認
$ df -hT -t nfs4
df: ‘/mnt/fsxn’: Stale file handle
df: ‘/mnt/fsxn/.snapshot/snaphost1’: Stale file handle

$ mount | grep nfs4
svm-0b0149bf226af89a4.fs-01f8ffb4adbf236d1.fsx.us-east-1.amazonaws.com:/vol1 on /mnt/fsxn type nfs4 (rw,relatime,vers=4.1,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.1.41,local_lock=none,addr=10.0.1.119)

# マウントポイントにアクセスできるか確認
$ ls -la /mnt/fsxn/
ls: cannot access /mnt/fsxn/: Stale file handle

# アンマウント
$ sudo umount /mnt/fsxn

# SVM2 の vol1 をマウント
$ sudo mount -t nfs svm-0b0c9e66d39afdc54.fs-01f8ffb4adbf236d1.fsx.us-east-1.amazonaws.com:/vol1 /mnt/fsxn/

# マウントされたことを確認
$ df -hT -t nfs4
Filesystem                                                                   Type  Size  Used Avail Use% Mounted on
svm-0b0c9e66d39afdc54.fs-01f8ffb4adbf236d1.fsx.us-east-1.amazonaws.com:/vol1 nfs4   95G  7.1G   88G   8% /mnt/fsxn

# マウントポイントにアクセス
$ ls -l /mnt/fsxn/
total 1052716
-rw-r--r-- 1 root root 1073741824 Dec 17 02:59 random_block_file_restore
drwxr-xr-x 2 root root       4096 Dec 17 06:26 snapshot_test
-rw-r--r-- 1 root root          5 Dec 17 05:58 test.txt

元々SVM1/vol1をマウントしていたのでアンマウントして、SVM2/vol2をマウントしたところアクセスできました。

エクスポートポリシーとスナップショットポリシーがリホスト後も引き継がれるのか

スナップショットポリシーの割り当て

先述した通り、エクスポートポリシーとスナップショットポリシーやQoSポリシーなど一部設定値はリホスト時に失われます。

ただし、ドキュメントからリホスト先のSVMに同一の名前の設定をしていた際にはどのような挙動をするのか記載がなかったので、試してみます。FSx for ONTAPにはデフォルトでfsx-root-volume-policyというエクスポートポリシーが作成されます。リホスト前のエクスポートポリシーにこちらのポリシーを設定して、どのような挙動をするのか確認します。

また、せっかくなのでリホスト先のSVMに存在しないスナップショットポリシーを作成し、ボリュームに作成したスナップショットポリシーを指定した場合の挙動も確認します。

まず、スナップショットポリシーを作成します。作成するスナップショットポリシーはevery_10_minという10分間隔でスナップショットを取得するものです。

# 現在のスナップショットポリシーの確認
::> snapshot policy show
Vserver: FsxId01f8ffb4adbf236d1
                         Number of Is
Policy Name              Schedules Enabled Comment
------------------------ --------- ------- ----------------------------------
default                          3 true    Default policy with hourly, daily & weekly schedules.
    Schedule               Count     Prefix                 SnapMirror Label
    ---------------------- -----     ---------------------- -------------------
    hourly                     6     hourly                 -
    daily                      2     daily                  daily
    weekly                     2     weekly                 weekly

default-1weekly                  3 true    Default policy with 6 hourly, 2 daily & 1 weekly schedule.
    Schedule               Count     Prefix                 SnapMirror Label
    ---------------------- -----     ---------------------- -------------------
    hourly                     6     hourly                 -
    daily                      2     daily                  -
    weekly                     1     weekly                 -

none                             0 false   Policy for no automatic snapshots.
    Schedule               Count     Prefix                 SnapMirror Label
    ---------------------- -----     ---------------------- -------------------
    -                          -     -                      -

3 entries were displayed.

# スナップショットポリシーの作成
::> snapshot policy create -vserver SVM2 -policy every_10_min -enabled true -schedule1 10min -count1 6 -prefix1 every_10_min

# スナップショットポリシーが作成されたことを確認
::> snapshot policy show
Vserver: FsxId01f8ffb4adbf236d1
                         Number of Is
Policy Name              Schedules Enabled Comment
------------------------ --------- ------- ----------------------------------
default                          3 true    Default policy with hourly, daily & weekly schedules.
    Schedule               Count     Prefix                 SnapMirror Label
    ---------------------- -----     ---------------------- -------------------
    hourly                     6     hourly                 -
    daily                      2     daily                  daily
    weekly                     2     weekly                 weekly

default-1weekly                  3 true    Default policy with 6 hourly, 2 daily & 1 weekly schedule.
    Schedule               Count     Prefix                 SnapMirror Label
    ---------------------- -----     ---------------------- -------------------
    hourly                     6     hourly                 -
    daily                      2     daily                  -
    weekly                     1     weekly                 -

none                             0 false   Policy for no automatic snapshots.
    Schedule               Count     Prefix                 SnapMirror Label
    ---------------------- -----     ---------------------- -------------------
    -                          -     -                      -

Vserver: SVM2
                         Number of Is
Policy Name              Schedules Enabled Comment
------------------------ --------- ------- ----------------------------------
every_10_min                     1 true    -
    Schedule               Count     Prefix                 SnapMirror Label
    ---------------------- -----     ---------------------- -------------------
    10min                      6     every_10_min           -

4 entries were displayed.

every_10_minというスナップショットポリシーを作成できました。

こちらのスナップショットポリシーをvol1に割り当てます。

# vol1 に every_10_min を割り当て
::> volume modify -vserver SVM2 -volume vol1 -snapshot-policy every_10_min

Warning: You are changing the Snapshot policy on volume "vol1" to "every_10_min". Snapshot copies on this volume that do
         not match any of the prefixes of the new Snapshot policy will not be deleted. However, when the new Snapshot
         policy takes effect, depending on the new retention count, any existing Snapshot copies that continue to use the
         same prefixes might be deleted. See the 'volume modify' man page for more information.
Do you want to continue? {y|n}: y
Volume modify successful on volume vol1 of Vserver SVM2.

# vol1 に every_10_min が割り当てられたことを確認
::> volume show -fields snapshot-policy
vserver volume    snapshot-policy
------- --------- ---------------
SVM1    SVM1_root default
SVM2    SVM2_root default
SVM2    vol1      every_10_min

エクスポートポリシーの割り当て

次にエクスポートポリシーfsx-root-volume-policyvol1に割り当てます。

# 各SVMに fsx-root-volume-policy があることを確認
::> export-policy show
Vserver          Policy Name
---------------  -------------------
SVM1             default
SVM1             fsx-root-volume-policy
SVM2             default
SVM2             fsx-root-volume-policy
4 entries were displayed.

# vol1 に fsx-root-volume-policy を割り当て
::> volume modify -vserver SVM2 -volume vol1 -policy fsx-root-volume-policy
Volume modify successful on volume vol1 of Vserver SVM2.

# vol1 に fsx-root-volume-policy が割り当てられたことを確認
::> volume show -fields policy
vserver volume    policy
------- --------- ----------------------
SVM1    SVM1_root fsx-root-volume-policy
SVM2    SVM2_root fsx-root-volume-policy
SVM2    vol1      fsx-root-volume-policy
3 entries were displayed.

リホスト

それではこの状態でリホストを行います。

# vol1 を SVM2 からアンマウント
::> volume unmount -vserver SVM2 -volume vol1
                                                                                                                           
# vol1 が SVM2 からアンマウントされたことを確認
::> volume show -vserver SVM2 -volume vol1 -fields junction-path
vserver volume junction-path
------- ------ -------------
SVM2    vol1   -

# vol1 を SVM2 から SVM1 にリホスト
::> volume rehost -vserver SVM2 -volume vol1 -destination-vserver SVM1

Warning: Rehosting a volume from one Vserver to another Vserver does not change the security information about that
         volume.
         If the security domains of the Vservers are not identical, unwanted access might be permitted, and desired access
         might be denied. An attempt to rehost a volume will disassociate the volume from all volume policies and policy
         rules. The volume must be reconfigured after a successful or unsuccessful rehost operation.
Do you want to continue? {y|n}: y
[Job 48] Job is queued: Volume rehost operation on volume "vol1" on Vserver "SVM2" to destination Vserver "SVM1" by adminis[Job 48] Job succeeded: Successful                                                                                         

Info: volume is rehosted on the target Vserver.
Set the desired volume configuration - such as the export policy and QoS policy - on the target Vserver.

# リホストされたことを確認
::> volume show
Vserver   Volume       Aggregate    State      Type       Size  Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
SVM1      SVM1_root    aggr1        online     RW          1GB    972.3MB    0%
SVM1      vol1         aggr1        online     RW        100GB    87.92GB    7%
SVM2      SVM2_root    aggr1        online     RW          1GB    972.5MB    0%
3 entries were displayed.

# リホストされた vol1 のエクスポートポリシーとスナップショットポリシーを確認
::> volume show -vserver SVM1 -volume vol1 -fields policy, snapshot-policy
vserver volume policy  snapshot-policy
------- ------ ------- ---------------
SVM1    vol1   default default

リホスト後のボリュームを確認すると、エクスポートポリシー、スナップショットポリシーどちらもdefaultとなっていました。どうやらリホスト先のSVMに同一の設定があろうとなかろうとデフォルトの値になるようです。

リホストをするときは注意事項をよく確認してリホスト前後の設定を照らし合わせよう

Amazon FSx for NetApp ONTAPのボリュームを別のSVMにリホストしてみました。

いくつか注意点はありますが特に詰まることはなく、あっさりとリホストすることができました。

ただし、実際に業務でリホストをするときは注意事項をよく確認した上で実施をしてください。特に、リホスト前後に引き継がれない情報を照らし合わして、リホスト後にどの設定を変更する必要があるのか明らかにするのが大切です。

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.